Info-Atari16 Digest Fri, 3 May 91 Volume 91 : Issue 245 Today's Topics: Advantages of Improved Mice? ATARI ARCHIVES autogem C c++ for the atari Can GCC treat printer like file? C compilers (was Re: C) DESKJET printer drivers floppy compatibility p Glendale Conference Impressions HELP!!!!!!!!!!!!!!!!!!!!!!!!!! Info-Atari16 Digest V91 #242 Mega STe Questions. Modem Capable Games fo New TOS versions ST GEM-based Word Processors Two More Mega STE Question. uudecoding multi-part files? Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 2 May 91 17:31:14 GMT From: noao!asuvax!ncar!zaphod.mps.ohio-state.edu!caen!uflorida!mailer.cc.fsu.edu!bind !boyd@arizona.edu (Mickey Boyd) Subject: Advantages of Improved Mice? To: Info-Atari16@naucse.cse.nau.edu In article <1991May1.213059.21272@milton.u.washington.edu>, iho@akbar.UUCP (Il Oh) writes: >glennd@athena.arc.nasa.gov (Glenn Deardorff - GDP) writes: >>I recently heard from someone who said that using an improved mouse >>(improved over the standard Atari mouse, that is) significantly improved >>the performance of his GEM windows - if I understood him right. That is >>to say, that windows would raise faster, grab the focus faster, etc. >>just by using an improved mouse - so that GEM would like it was >>significantly speeded up. He said he used a "Golden Image" mouse. Do >>others that have bought better mice notice anything like this? If so, >>it would certainly seem like a worthwile investment. > >I seriously doubt that GEM would perform faster because of a better mouse. >However, you would be able to use it faster. A better mouse responds more >quickly to your movements and clicks. The Golden Image is supposed to be >very good, a lot like the Microsoft Mouse for DOS machines. I've tried >the Beetle mouse, and it's also very nice. I'm one of the lucky few. >I've got a really good Atari mouse. Beware! Faster mice (ie higher dpi) are not always better. At some point, the ST hardware cannot handle the increased input, and you get the 'sticking pointer' problem. Try this: move your Atari mouse very quickly in any direction (I mean VERY quickly, like a snap). You will notice that the mouse pointer will kind of "shudder", but will not move in the desired direction. Basically, you are overloading hardware/software with too much mouse output. Now, the higher dpi mice give more output per inch moved. This means that this overload is easier to attain with the higher dpi mice. I have a buddy who cannot use his Golden Image mouse because he would have to "pace" himself to get it to work. A better way to get a "faster" mouse is through software acceleration, which should not have this problem (and you can choose from direct, proportional, exponential, etc, types of acceleration). There are several PD accelerators which work well (I use MouseDoubler2). Thus, if you are considering purchasing a third-party mouse, make sure that the dpi is not too high (unfortunetely the marketeers seem to think that bigger is better when it comes to dpi). Failing that, you should find out if you can set the dpi rate with a dip switch or pot or something. I believe the Atari mice are rated at 150dpi. I have seen mice advertised at up to 400dpi (thus meaning that you would have to move the mouse only about 1/3 as fast to get it to "shudder"). You will often see ads proclaiming "No mouse accelerator needed!" on such mice. This is true, but the damn things force you to slow down (and at least in my case, miss what I am trying to point at)!! -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Kirk to Enterprise. All clear FSU Computer Science | down here. Beam down Technical Support Group | yeoman Rand and a six-pack . ." email: boyd@fsucs.cs.fsu.edu | ---------------------------------+------------------------------------- ------------------------------ Date: 2 May 91 16:48:00 GMT From: @uunet.uu.net (JIM DEVONSHIRE) Subject: ATARI ARCHIVES To: Info-Atari16@naucse.cse.nau.edu How do I access files in the Atari archives. Do I have to subscribe, pay a fee, join an organization? OR are they free to any interested user? Regards, Jim Devonshire at Erin Ontario Canada --- ------------------------------ Date: 2 May 91 18:08:00 GMT From: news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose!jim.devonshire@uunet.uu .net (JIM DEVONSHIRE) Subject: autogem To: Info-Atari16@naucse.cse.nau.edu To: rmacgreg@cs.strath.ac.uk Thanks for the feedback. I've tried a few variations but without success. My brother mentioned that he thought "Little Green" may be interfering with the execution of the "Bootmaker" program. I'll remove LG completely from the configuration process. Yes, I've used a text editor and looked at the file(s) contents but I really don't know what I'm looking for. There is bin code and ascii text intermingled in the bootmaker and autoboot programs. The auto boot program shows the file path and name of the program to be autobooted "a:\pro24.prg" as well as machine language? P.S. Do you "correspond" with anyone in Christchurch or Manchester or Portsmouth? Regards....Jim, Erin, Ontario, Canada. --- ------------------------------ Date: 2 May 91 14:56:20 GMT From: mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer@uunet.uu.net (Klamer Schutte) Subject: C To: Info-Atari16@naucse.cse.nau.edu In <5838@eastapps.East.Sun.COM> gaudreau@juggler.East.Sun.COM (Joe Gaudreau (Dances with PostScript)) writes: >Look for Borland C++ sooner or later - The rumor line says this is hot! Has anybody run this for the ST??? I will be >>very<< interested! (How about this deal: I get the program, and i will translate the docs ???) (Assuming docs are still in german.) Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer ------------------------------ Date: 2 May 91 03:59:45 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!rpi!uupsi!TALOS!jerry@arizona.edu (Jerry Gitomer) Subject: c++ for the atari To: Info-Atari16@naucse.cse.nau.edu tkramp@aragon.stgt.sub.org (Thorsten Kramp) writes: :Hi folks, :a friend of mine is looking for a C++ implementation for the :Atari ST (I only know about MPW C++ for the Macintosh, which :I use, and the Borland and Zortech compilers for PCs). Any :hints would be helpful - tnx 1.0e6 in advance. GNU g++ from the free software foundation is available on OS-9 (and I think on GEM -- although I can't remember who ported it or where it is). -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: ...uunet!uupsi!npri6!jerry ) ------------------------------ Date: 2 May 91 16:21:44 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!snorkelwacker.mit.ed u!bloom-beacon!eru!hagbard!sunic!isgate!krafla!adamd@arizona.edu (Adam David) Subject: Can GCC treat printer like file? To: Info-Atari16@naucse.cse.nau.edu In <1991Apr26.044146.19629@watmath.waterloo.edu> ljdickey@watmath.waterloo.edu (L.J.Dickey) writes: [discussion of PRN: LST: AUX: CON: etc. deleted] >Is there a standard filename for the serial port? Try stdaux, some compilers reserve that name for the serial port. Don't know about gcc though. -- Adam David. (adamd@rhi.hi.is) ------------------------------ Date: 2 May 91 15:07:26 GMT From: mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer@uunet.uu.net (Klamer Schutte) Subject: C compilers (was Re: C) To: Info-Atari16@naucse.cse.nau.edu In <1991Apr30.193021.10443@newcastle.ac.uk> D.C.Halliday@newcastle.ac.uk (Dave Halliday) writes: Some changes to the C compiler table ->name memory src price ANSI Debuger Notes ->---------------------------------------------------------------------------- ->GNU C 2Meg+ yes nil Y poor for ST UNIX origins ->Sozobon C 520K yes nil N none?? PD Low Level ->MW C 520K no #110 N Src Level No longer updated ->Prospero C 520K no #100 Y Src Level Links to other Prospro langs ->Turbo C ?? no ?? Y Src Level Only in german R 1Meg+ ->Lattice V5 R 1Meg+ no #110 Y Low Level Optomiser ->Laser C R 1Meg+ no #100 N Src Level Very fast compile times ->---------------------------------------------------------------------------- ->Notes: Prospro C links with other Prospro product because it uses the GST ->format and not a propriety format. Some other compiler may offer GST link ->format also (I know Lattice C offers both GST and Lattice libraries.) ->The R in the memory section indicates that 1meg of memory is recomended but ->the compiler can be run in 520K. ->As a recomendation I would say the following if you have lots of memory, hard ->disk and no need for commercial support or documentation go for GNU C. If on ->a budget and have a less powerfull setup Sozobon should serve you well. If ->good profesional support is your prime thought I would recomend Prospro C. ->Turbo C is good if you read german. If executable efficiency is your prime ->criteria then Lattice C can't be beeten (though Turbo C is close). Finally if I think TurboC is a bit faster in execution times than Lattice C. But TurboC has 16 bits ints where Lattice has 32 bits -- thats the difference. ->compile speed is required then Laser C is the best bet (I'ts one pass Hmmm. TurboC is also one-pass. And very fast compilation! Also its integrated edit-compile environment is a very nice way to write && debug GEM programs (also due to its build-in online GEM manual). ->compiler compiles at an order of magnatude faster than many of the ->other compilers.) When one wants to compile U*IX programs conformance to U*IX libaries is also important. Of the compilers i know the order of compliance is: GNU - MWC - Sozobon - TurboC. I don't know about the other ones. ->So each compiler has its strengths. True. ->For those wondering what my bias is I own GNU C and Lattice C Vsn5. I own GNU (but not enough memory :-(), Sozobon (slightly buggy && slow compilation), MW C (Unix like environmemt), Megamax (Old version of LaserC), MJ C (An old PD C version -- slow, subset of K&R) and TurboC (Fast in compile && execute, but ANSI only -- a drawback sometimes). Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer ------------------------------ Date: 2 May 91 13:27:13 GMT From: mcsun!ukc!strath-cs!glasgow!wilsona@uunet.uu.net (Alan Wilson) Subject: DESKJET printer drivers To: Info-Atari16@naucse.cse.nau.edu Whilst on the subject of printer drivers in general, could someone post details of the 'printer.sys' file most commonly found referred to in the 'assign.sys' with driver ID 21 ? I have a printer which emulates an Epson, but most Epson drivers do not use the quadruple density graphics mode which my printer has. I have tried hacking the printer.sys file... I can get the printer into the correct mode, but the driver only sends enough data for 960 dots per inch, whilst I want 1920. A posting of this files structure would be of great help to me - output from timeworks is really horrible, I'm sure my printer can do better. Alan Wilson -- ############################################################################### # /\ / Alan # USEnet : wilsona!glasgow!mcsun!... # ------------------------------ Date: 2 May 91 16:46:00 GMT From: news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose!jim.devonshire@uunet.uu .net (JIM DEVONSHIRE) Subject: floppy compatibility p To: Info-Atari16@naucse.cse.nau.edu To:ytsuji@wucc.waseda.ac.jp Sorry, I can't answer your "byte" questions, but as to your incompatibilities, I know there are a couple of programs which will allow your PC to read Atari 3-1/2" disks from your PC's 3-1/2" drive. The program I use is called STTOPC.arc or zip. Regards, Jim Devonshire at Erin Ontario Canada --- ------------------------------ Date: 2 May 91 17:41:36 GMT From: mcrware!mwca!bill@uunet.uu.net (Bill Sheppard) Subject: Glendale Conference Impressions To: Info-Atari16@naucse.cse.nau.edu In article <1991May1.180512.2572@cs.ucla.edu> stephen@oahu.cs.ucla.edu (Steve Whitney) writes: `In article <2623@lee.SEAS.UCLA.EDU> plinio@babbage.seas.ucla.edu (Plinio Barbeito) writes: ``In article <12733@uhccux.uhcc.Hawaii.Edu> kiki@uhunix1.uhcc.Hawaii.Edu (Jack W. Wine) writes: ``>>plinio@curtiss.seas.ucla.edu (Plinio Barbeito/) writes: ``>This is really puzzling news! If Atari built a factory in Israel, it can't ``>possibly be dedicated to only floppy controller chip production... `` ``Sorry to have implied that. I don't know if it will be dedicated to ``that sole purpose. That's all that Bob mentioned about it, though. ` `I didn't think he said it would be a factory. Sounded to me like they had `hired people to reverse engineer the WD1772 and do a layout for one that `would run faster. Both the San Jose Mercury News and the Jewish Bulletin reported that Atari and the Israeli government are negotiating (close but nothing signed yet) for Atari to open a manufacturing plant in Israel, with significant incentive (financial) from the Israeli government, who are hoping to start a high-tech business park. The plant would apparently produce most types of Atari hard- ware (though I believe the Singapore plant would remain) and would give (again, I'm not positive) Atari major advantages in dealing with the EC. -- ############################################################################## # Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill # # Microware Systems Corporation --- OS-9: Seven generations beyond OS/2!! # ######Opinions expressed are my own, though you'd be wise to adopt them!###### ------------------------------ Date: 1 May 91 20:01:00 GMT From: arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!caen!sol.ctr.columbia.edu!i ra.uka.de!smurf!artcom0!hb.maus.de!ac2.maus.de!Lutz_Frank@arizona.edu (Lutz Frank) Subject: HELP!!!!!!!!!!!!!!!!!!!!!!!!!! To: Info-Atari16@naucse.cse.nau.edu Hi Jeffery, jd> Atari Megafile 30 in partition D have become invisible. The problem jd> started when I was using Cheetah to copy some files from logical drive E jd> to D. For one copy it either said that it couldn't find the drive path I got the same problem using CHEETAH on BGM-partitions of my harddisk. There I could only save one of the BGM-partitions. Cheetah destroyed the root sector of the destination hard disk. If you have a monitor like DISKUS you can try to restore the root-sector. (I didn't have had this programm at this time - I lost all since last backup ... ;-( ). Now I have a collection of copies of my root sectors on a special disk - just for case of emergency ... Kind regards Lutz ------------------------------ Date: Fri, 03 May 91 12:24:28 CDT From: Mike Dorman Subject: Info-Atari16 Digest V91 #242 To: Atari List About the ICD adapter software-- In their distribution, they explicitly state that it may not be redistributed on BBSs and such--the only online site you may get it from is GEnie. Possibly the one failing of an otherwise very level-headed company. Mike. ------------------------------------------------------------------------------- : Michael Alan Dorman : : : MDORMAN1@UA1VM.UA.EDU : Hobbies are things people do when they should be : : BIX: syssupport : sleeping. --M.A.D. : : GEnie: M.DORMAN2 : : : PostalNet: : : : Box 8068 : Stonehenge was built by two drunks with no : : Tuscaloosa, AL : witnesses. --P.S.McGhee : : 35486 : : ------------------------------------------------------------------------------- ------------------------------ Date: 2 May 91 19:40:01 GMT From: oahu.cs.ucla.edu!stephen@locus.ucla.edu (Steve Whitney) Subject: Mega STe Questions. To: Info-Atari16@naucse.cse.nau.edu In article <41920@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >I doubt anyone in the US has seen a Mega STe 1 yet, but the reports on >the F-Net feeds are that Atari has purposely crippled the system (similar >to the way they crippled the Mega ST2) to prevent upgrading it. > >The pc board is cut off where the host adapter would be, and the plastic >case has been redesigned to prevent intalling a hard drive mechanism. NO NO NO. The case has not been "redesigned" to prevent anyone from installing a hard disk in it. The case is not finished on the Mega STe1. To install the hard disk, they apparently have to remove some posts from the mold, and in the no-hard-disk version, they, naturally, haven't done this. I can't speak to the host adapter issue, but I doubt very much that the PC board has been deliberately cut off to prevent you from installing one. I have even heard that Atari is working with a host adapter manufacturer which might provide an add-on for the MSTe1. >BobR -- Steve Whitney - UCLA CS Grad Student (())_-_(()) Soon to be working at Silicon Graphics | (* *) | Internet: stephen@cs.ucla.edu UCLA Bruin--> { \_@_/ } GEnie: S.WHITNEY `-----' ------------------------------ Date: 2 May 91 16:47:00 GMT From: news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose!jim.devonshire@uunet.uu .net (JIM DEVONSHIRE) Subject: Modem Capable Games fo To: Info-Atari16@naucse.cse.nau.edu To: mathew@mantis.co.uk One modem capable game I use is Battle Chess. My brother and I play on a regular basis. Regards: Jim Devonshire, Erin, Ontario, Canada --- ------------------------------ Date: 2 May 91 16:03:59 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.e du!bloom-beacon!eru!hagbard!sunic!isgate!krafla!adamd@arizona.edu (Adam David) Subject: New TOS versions To: Info-Atari16@naucse.cse.nau.edu In <672747111.0@egsgate.FidoNet.Org> Shervin.Shahrebani.Of.250/744@f744.n250.z1.FidoNet.Org (Shervin Shahrebani Of 250/744) writes: >You don't need Pinhead if you have TOS 1.4 and above. I have a Mega STE and >have experienced the problem as well but Pinhead is nothing compared to the >TOS's built in fast load. Why bother when TOS has it already? I know >pinhead may be compatible with a few more packages but there is nothing to >it. Doesn't Pinhead simply compress executables into a self-extracting form that takes less disk space and therefore less time to load? Is this what TOS 1.4 fastload does, or is there any benefit in using both methods? The time to load an application program is perhaps not a very significant factor if the program is just to be loaded in and much time then spent working in the program. On the other hand major savings in disk space matter quite a lot to most users - from single floppy machines up to Gigabyte hard disks. The shorter load time is just a useful side effect of the data compression and is paid for by the time taken to compress the files (also the extra CPU load during uncompression in a multiprogramming environment). -- Adam David. (adamd@rhi.hi.is) ------------------------------ Date: 2 May 91 16:25:54 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!wuarchive!csus.edu!ucdavis!csusac!csuchico. edu!ekrimen@arizona.edu (Ed Krimen) Subject: ST GEM-based Word Processors To: Info-Atari16@naucse.cse.nau.edu In article <24554@well.sf.ca.us> fh@well.sf.ca.us (Fabian Hahn) writes: A > >Even though you mentioned that you do not need a document processor >I would like to use the opportunity to plug Wordflair II. I use >Wordflair II for all my text processing on the Atari (the reason for that >is that I have written some parts of it). > Aw, gee whiz, juuuust a little bias here. :~) But at least you told us. > >I get all this with decent looking output (yes it works great with FSM) All righty, now, does it come with FSM GDOS? If not, how do we get it? If not, we still get to use crummy ol' GDOS until Atari decides to release FSM GDOS? BTW, does FSM GDOS work as a direct replacement to GDOS, like G+Plus, or do the programs which currently run GDOS, have to be modified to look for FSM? -- ||| Ed Krimen [ekrimen@ecst.csuchico.edu or al661@cleveland.freenet.edu] ||| Video Production Major, California State University, Chico / | \ SysOp, Fuji BBS: 916-894-1261 ------------------------------ Date: 2 May 91 14:12:45 GMT From: mcsun!ukc!newcastle.ac.uk!milfield!ndch@uunet.uu.net (Dave Halliday) Subject: Two More Mega STE Question. To: Info-Atari16@naucse.cse.nau.edu This question was propted by the resent discussion about TT hard drives. (1) Can the Atari ASCI-SCSI addapter and software on the Mega STE support more than one SCSI device? (2) Am I correct in assuming that the Mega STE comes with a battery backed real time clock? Thanks, Dave H. (D.C.Halliday@newcastle.ac.uk) ------------------------------ Date: 30 Apr 91 15:17:03 GMT From: arizona.edu!cerritos.edu!nic.csu.net!usc!elroy.jpl.nasa.gov!lll-winken!aunro!er sys!ggranger@arizona.edu (Greg Granger) Subject: uudecoding multi-part files? To: Info-Atari16@naucse.cse.nau.edu alten@hpcvia.CV.HP.COM (John_Altendorf) writes: > Can anyone please explain the requirements for file names in order to > uudecode a multi-part file? I seem to recall something like the file > names must be sequentially named file.uaa, file.uab file.uac etc. Also > it seemed that the ----end---- line of the file had to have some notation > in it. Please clarify my misunderstandings. > > > John Altendorf alten@hpcvia.cv.hp.com > Hewlett-Packard > Corvallis, Oregon I believe to uudecode one file into multi-parts, you have to use the -x (where x is the no. of lines that you want in the uue file). To UUE, say for instance, a 100K file called DUMMY.LZH, on the command line, type: -700 DUMMY.LZH. This will create a series of uuencoded files that are 700 lines long (except for the last file, which will be the remainder, but not necessarily 700 lines long). Greg Granger | INet: ersys!ggranger@nro.cs.athabascau.ca | | Fnet: Greg Granger (Node 532) Dark Knight (Node 595)| | Post: 5906-188 Street Edmonton, AB Canada T6M-2A9 | | Tele: +1 403 481-0803 OR +1 403 481-5110 | Greg Granger ersys!ggranger@nro.cs.athabascau.ca Edmonton Remote Systems: Serving Northern Alberta since 1982 ------------------------------ End of Info-Atari16 Digest ******************************